-
Notifications
You must be signed in to change notification settings - Fork 19
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update contract #2314
Update contract #2314
Conversation
Warning Rate limit exceeded@nick-bisonai has exceeded the limit for the number of commits or files that can be reviewed per hour. Please wait 21 minutes and 36 seconds before requesting another review. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. 📝 Walkthrough📝 Walkthrough📝 Walkthrough📝 Walkthrough📝 Walkthrough📝 WalkthroughWalkthroughThe Changes
Possibly related PRs
Suggested reviewers
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 0
🧹 Outside diff range and nitpick comments (1)
contracts/v0.2/src/SubmissionProxy.sol (1)
467-499
: Consider adding a return value for better client feedback.The implementation correctly handles the submission order issue by:
- First checking if the submission is newer
- Then validating freshness and other requirements
However, the silent return for outdated submissions might be confusing for clients. Consider returning a boolean to indicate whether the submission was processed:
-function submitSingleIfNew(bytes32 _feedHash, int256 _answer, uint256 _timestamp, bytes calldata _proof) public { +function submitSingleIfNew(bytes32 _feedHash, int256 _answer, uint256 _timestamp, bytes calldata _proof) public returns (bool) { if (lastSubmissionTimes[_feedHash] >= _timestamp) { - return; + return false; } // ... rest of the function ... if (validateProof(_feedHash, message_, proofs_)) { feeds[_feedHash].submit(_answer); lastSubmissionTimes[_feedHash] = _timestamp; + return true; } else { revert InvalidProof(); } }
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (1)
contracts/v0.2/src/SubmissionProxy.sol
(2 hunks)
🔇 Additional comments (2)
contracts/v0.2/src/SubmissionProxy.sol (2)
40-41
: LGTM: Enhanced visibility improves client accessibility.
The change to make these mappings public is a good improvement as it:
- Allows clients to query last submission times, helping them make informed decisions about submissions
- Provides transparency about threshold values
448-465
: LGTM: Well-structured batch submission function.
The implementation:
- Maintains consistent input validation with other submit functions
- Efficiently delegates to submitSingleIfNew for individual submissions
- Addresses the PR objective by handling only newer submissions
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM! I think we can go only with making the mappings public, rather than creating a new submission methods 🙏
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 1
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (1)
contracts/v0.2/src/SubmissionProxy.sol
(3 hunks)
🔇 Additional comments (3)
contracts/v0.2/src/SubmissionProxy.sol (3)
40-41
: LGTM! Visibility changes improve transparency
Making these mappings public allows clients to query submission times and thresholds directly, helping them understand submission failures better.
64-65
: LGTM! Improved error handling with specific error types
The new error types AnswerOutdated
and AnswerSuperseded
provide clear distinction between different failure scenarios, helping clients better understand why their submissions failed.
424-425
: LGTM! Clear handling of superseded submissions
The check for superseded submissions is correct and uses consistent timestamp units. The error provides clear feedback when a newer submission has already been processed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 1
🧹 Outside diff range and nitpick comments (1)
contracts/v0.2/src/SubmissionProxy.sol (1)
420-451
: Consider extracting common validation logic.Both
submitSingle
andupdatePrice
share significant validation logic. Consider extracting these common validations into a private function to improve maintainability and reduce code duplication.Example refactor:
+ function validateSubmission(bytes32 _feedHash, int256 _answer, uint256 _timestamp, bytes calldata _proof) + private + returns (bytes[] memory proofs_) + { + if (_timestamp <= ((block.timestamp - dataFreshness) * 1000)) { + revert AnswerOutdated(); + } + + (proofs_, bool success_) = splitProofs(_proof); + if (!success_) { + revert InvalidProofFormat(); + } + + if (address(feeds[_feedHash]) == address(0)) { + revert FeedHashNotFound(); + } + + if (keccak256(abi.encodePacked(feeds[_feedHash].name())) != _feedHash) { + revert InvalidFeedHash(); + } + + return proofs_; + }Also applies to: 469-492
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (1)
contracts/v0.2/src/SubmissionProxy.sol
(3 hunks)
🔇 Additional comments (5)
contracts/v0.2/src/SubmissionProxy.sol (5)
40-41
: LGTM: Public mappings enhance transparency.
The change to make thresholds
and lastSubmissionTimes
mappings public aligns with the PR objective of allowing clients to access this information for better decision-making.
64-65
: LGTM: Improved error handling with descriptive errors.
The renaming from AnswerTooOld
to AnswerOutdated
and addition of AnswerSuperseded
provides clearer distinction between different failure scenarios:
AnswerOutdated
: Data is older than the freshness thresholdAnswerSuperseded
: A newer submission was already processed
453-466
: LGTM: New updatePrices function handles superseded data gracefully.
The updatePrices
function provides a more lenient approach by:
- Continuing execution when answers are superseded (via
updatePrice
) - Still maintaining data integrity by validating proofs
- Properly handling other error cases
469-475
: LGTM: updatePrice implements the desired behavior.
The updatePrice
function successfully addresses the PR objective by:
- Still rejecting outdated data (older than freshness threshold)
- Silently skipping superseded data instead of reverting
- This allows clients to better understand why their submissions failed
420-426
:
Timestamp comparison needs parentheses for clarity.
The timestamp comparison could be clearer with proper parentheses grouping.
Apply this fix:
-if (_timestamp <= (block.timestamp - dataFreshness) * 1000 ) {
+if (_timestamp <= ((block.timestamp - dataFreshness) * 1000)) {
* chore: superseeded review * fix: fix test --------- Co-authored-by: nick <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 0
🧹 Outside diff range and nitpick comments (2)
contracts/v0.2/test/SubmitStrict.t.sol (1)
Line range hint
30-35
: Consider parameterizing contract addresses.The test uses hardcoded addresses for both
SubmissionProxy
andFeedRouter
contracts. This makes the test brittle and environment-dependent.Consider:
- Moving addresses to a configuration file
- Using constructor parameters
- Implementing a test fixture that deploys fresh contract instances
Example approach:
contract SubmitStrictTest is Test { SubmissionProxy public sp; FeedRouter public fr; function setUp() public { // Deploy or load from config sp = new SubmissionProxy(); fr = new FeedRouter(); } }Also applies to: 39-40
contracts/v0.2/src/SubmissionProxy.sol (1)
Line range hint
509-544
: Fix potential race condition in updatePrice.There's a potential race condition between the initial timestamp check and the final submission. The second check at lines 538-540 is correct but could be optimized.
Apply this fix to remove the redundant check and prevent the race condition:
function updatePrice(bytes32 _feedHash, int256 _answer, uint256 _timestamp, bytes calldata _proof) public { if (lastSubmissionTimes[_feedHash] >= _timestamp) { // answer is superseeded -> skip submission return; } if (_timestamp <= (block.timestamp - dataFreshness) * 1000) { // answer is not fresh -> do not submit! revert AnswerOutdated(); } (bytes[] memory proofs_, bool success_) = splitProofs(_proof); if (!success_) { // splitting proofs failed -> do not submit! revert InvalidProofFormat(); } if (address(feeds[_feedHash]) == address(0)) { // feedHash not registered -> do not submit! revert FeedHashNotFound(); } if (keccak256(abi.encodePacked(feeds[_feedHash].name())) != _feedHash) { // feedHash not matching with registered feed -> do not submit! revert InvalidFeedHash(); } bytes32 message_ = keccak256(abi.encodePacked(_answer, _timestamp, _feedHash)); if (validateProof(_feedHash, message_, proofs_)) { - if (lastSubmissionTimes[_feedHash] >= _timestamp) { - return; - } feeds[_feedHash].submit(_answer); lastSubmissionTimes[_feedHash] = _timestamp; } else { revert InvalidProof(); } }The redundant check at lines 538-540 should be removed as it creates a race condition window between the initial check and the final submission. The initial check at the start of the function is sufficient.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (2)
contracts/v0.2/src/SubmissionProxy.sol
(5 hunks)contracts/v0.2/test/SubmitStrict.t.sol
(1 hunks)
🔇 Additional comments (8)
contracts/v0.2/test/SubmitStrict.t.sol (2)
Line range hint 30-35
: Method name updated to reflect batch functionality.
The change from submitStrict
to submitStrictBatch
better reflects the batch nature of the operation. However, with the recent changes to the SubmissionProxy
contract that add new functions for handling submissions, we should ensure comprehensive test coverage.
Let's verify the test coverage for the new functionality:
Line range hint 46-49
: Verify timestamp validation for the new submission scenarios.
Given the PR's focus on timestamp-related submission issues, ensure the timestamp validation in the test adequately covers the edge cases mentioned in the PR objectives (user a/b submitting at timestamps 8/9).
Let's check for related test cases:
contracts/v0.2/src/SubmissionProxy.sol (6)
40-41
: LGTM! Public mappings improve transparency.
The change to make thresholds
and lastSubmissionTimes
mappings public aligns with the PR objective of allowing clients to access submission timing information.
64-65
: LGTM! Improved error naming and handling.
The renaming from AnswerTooOld
to AnswerOutdated
and addition of AnswerSuperseded
provides clearer error distinction between outdated timestamps and superseded submissions.
Line range hint 400-426
: LGTM! Clear batch submission with strict validation.
The submitStrictBatch
function provides a clean interface for submitting multiple prices with proper validation through submitStrictSingle
.
436-470
: LGTM! Comprehensive validation in submitStrictSingle.
The function properly validates:
- Timestamp freshness
- Submission order
- Proof format
- Feed registration
- Feed hash matching
- Proof validation
481-496
: LGTM! Non-strict batch update implementation.
The updatePrices
function provides a more flexible alternative that skips superseded submissions instead of reverting the entire batch.
437-437
: Verify timestamp comparison units.
The timestamp comparisons in both submitStrictSingle
and updatePrice
functions need parentheses for clarity, as flagged in past reviews:
Apply this fix to both occurrences:
-if (_timestamp <= (block.timestamp - dataFreshness) * 1000) {
+if (_timestamp <= ((block.timestamp - dataFreshness) * 1000)) {
Also applies to: 515-515
will be good to have, but since the logic is pretty much same as submitStrict but with one less condition, I considered it not necessary |
Description
There have been a client request with submission proxy contract
This update tries to fix following scenario
user a
anduser b
tries to submit in a same block.timestamp 10user a
received dal timestamp with 8 whileuser b
received dal timestamp with 9user a
anduser b
submits at the same time, if the execution order becomes b->a,user a
fails to submit the price.if the submission fails, client can't tell whether it is caused by data freshness failure, or because if there was a newer submission ahead.
it is hard for client to make decision with the latest round data even if the submission error is ignored
there are 2 approaches that could be taken
lastSubmissionTimes
public so that client can utilize lastSubmissionTimesType of change
Please delete options that are not relevant.
Checklist before requesting a review
Deployment